Gate admin design system by inbox access - #1439

Changes

• Restrict Design System Show the admin design-system navigation and resolve its route only for principals granted the existing inbox permission; direct unauthorized requests to canonical, legacy /design, and trailing-slash routes return not found.
• Share Email Allowlist Reuse one case-insensitive INBOX_USERS matcher across the web inbox/calendar surfaces and the admin surface, including the existing all override. Register it once as an optional operator secret for both components so supported deployments inject the same private value without committing addresses.
• Verify Both States Cover allowlisted and denied routes, permission bootstrap, navigation behavior, case normalization, inbox behavior, and deployment-secret routing; 230 admin tests, 29 focused web tests, and 72 focused CLI deployment tests pass with plugin and CLI typechecks, focused lint, formatting, and live UI QA.

Screenshots

• Allowlisted The existing Design system entry appears at the bottom of the admin navigation.

• Not Allowlisted The admin navigation ends at Crons and does not expose the Design system entry.

Risk assessment

• Stylistic frontend only: No The change alters route authorization, permission data flow, navigation availability, and deployment-secret routing.
• Logic changes: Present The Design System now reuses the existing Inbox and Calendar allowlist, and deployment tooling routes that same private value to the admin runtime.
• Security risk: Low The change narrows access, adds no new authentication mechanism or public endpoint, stores no addresses in Git, and fails closed when the allowlist is absent or incorrect.
• Risk level: High · Safe to auto-merge: No “High” is the repository's categorical label for permission changes, not an assessment that major breakage is likely. The practical blast radius is limited to visibility and access for three opt-in UI surfaces: it cannot modify stored data, run migrations, affect core agent execution, change billing, or alter public APIs. The credible failure mode is temporary denial of those surfaces from a misconfigured allowlist rather than unauthorized disclosure, but permission changes still warrant explicit human review.